Volume 1

Issue 2

June 2004

Best Practices Strategies for Optimum Reuse Ann Rockley, The Rockley Group, Inc. Cori Czekaj, Arbortext Reuse is a critical component of a unified content strategy. At each stage of developing the information architecture, information architects refine the reuse strategy to reflect multiple perspectives of reuse, culminating in an optimal reuse plan. This article provides guidance on how to achieve optimum reuse. Every project we undertake involves reuse within information products (e.g., in the body of a document and in the quick reference section in the appendix), across information products (e.g., call center materials, brochures, documentation, training), and across media (e.g., web, paper, wireless), but designing optimum reuse requires a balance between what is desired with what is possible from both an authoring and a technical perspective. An optimum reuse strategy is based on our analysis of the documents, the potential for reuse, and the end user content requirements, as well as on our understanding of the technical capabilities/implementation of the content management system and its users. Optimum reuse is also impacted by granularity and the types of people who use the reusable objects. Granularity Reuse is based on granularity. Granularity identifies the smallest piece of information that is reusable. There are typically multiple levels of reuse within your information set. In one instance you may reuse large sections of information unchanged; in others, you may reuse content at the sentence or even the word level. Defining the appropriate level of granularity can be challenging because if the granularity is too large, you may have to delete a significant portion of the content that is not applicable when you reuse an object. This may result in a lot of derivative reuse. Alternatively, if the granularity is too fine (small), content is more difficult to manage and track (e.g., the performance of some content management systems may be impacted by large numbers of small objects). Granularity will vary depending upon the users of the reusable objects (e.g., authors, reviewers and translators) and the technology. Authors Authors tend to prefer a more granular approach to content, in which the elements are identified semantically. The semantic structure gives them very clear guidelines on what to write (see the article on Semantic vs generic elements in the Information Architecture section of this issue). When elements are named semantically, they can be easily identified for storage as separate content objects. Fine granularity also makes it easy for authors to identify content for reuse or filtering (e.g., steps 1-3 in a procedure are relevant to all customers, but step 4 is only relevant to expert users). Reviewers/translators One of the wonderful features of object-oriented content management is that we can identify the elements that have changed and route only the changed elements to reviewers or translators. However, reviewing small elements of content out of context of the surrounding content can be problematic because the element may not make sense on its own, or may appear inaccurate the way it is used. Similarly, translators cannot translate an element unless they understand the context in which it is being used. Reviewers and translators may require a higher level of granularity, such as a sub-section or even a complete section. Compliance and legal officers may also want to see the entire document to ensure that the content is correct in the overall context. To achieve this balance, consider routing large elements for review and translation, but ensure that the element for review is clearly identified so that reviewers/translators work with only the required elements, not ones they have already seen. In this way, reviewers and translators can see content in the overall context and make appropriate changes to the specified information element. Technology Granularity is also impacted by technology. Too small a level of granularity can be very difficult to manage, yet too large a level of granularity may make it very difficult for users to retrieve and reuse elements. Look at your content and determine if you need to "burst" (break your content into its component parts and store the content at that level of granularity in the CMS) at every element. Would nested reuse make sense instead of bursting? Remember that authors don't want to look for small fragments of content either. Can you take the element size to the next level (e.g., instead of a small element, such as a step, would a whole procedure be a more realistic size for authors to retrieve and for the CMS to manage)? The larger the object, the easier it is for authors to manage and retrieve. Larger content objects can also be more technology friendly. The performance of content management and composition systems is often related to the number of information elements being stored and retrieved. Implementation challenges You've done all your modeling and you know what type of reuse is required, but now you have to figure out how to implement it. This section describes some of the implementation challenges for authors, architects, editors/reviewers/translators, and implementers, and suggests how you can overcome them. Authors Implementation issues for authors include: Granularity Metadata As previously described, authors like to be guided in their authoring by richly semantic models. In an XML-based content management system every element can be burst apart and stored separately. It is easy to burst content based on its semantic structure because semantically-named elements have more meaning for retrieval (e.g., it makes more sense to retrieve a "procedure" than an "ordered list"). However, if you have a very rich semantic structure (e.g., procedure contains steps and steps contain action and result) and you choose to burst the content at every semantic element, authors may have difficulty searching for appropriate content. Authors generally don't want to search for small reusable fragments (e.g., steps). Consider a nested reuse strategy, allowing authors to have small fragments of content within a single element. Nested reuse also solves the problem of having to write out of context (e.g., writing step 4 on its own, out of context of the entire procedure). Nested reuse allows authors to write a complete set of information in context, yet filter out specific pieces of the content where appropriate. Also consider providing a semantic authoring stylesheet that "maps" to a more generic structure (e.g., DTD/Schema). This ensures that authors have the semantic structure for authoring, but a more simplified DTD/Schema for creation and maintenance. Metadata is also needed to identify and retrieve content. If you don't have enough metadata you may not be able to effectively retrieve content; however, too much metadata makes the authoring task onerous. Authors can be intimidated by having to add too much metadata. Wherever possible consider automating the addition of metadata through functions like inheritance and reduced metadata lists (e.g., show only the metadata that is relevant in the context of the content). Also, consider using a semantic authoring template that maps to a generic DTD/schema and maps the semantic element in the authoring template to appropriate metadata. Content/information architect Content/information architects are responsible for designing an optimum reuse strategy that is represented in the models and in the implementation strategy. Implementation issues for content/information architects include: Understanding the full breadth of content and organizational requirements Simplifying content models yet at the same time optimizing authoring and implementation Providing appropriate guidelines for reuse Content/information architects need to see the whole breadth of content in an organization (or a representative sample) and look for opportunities for reuse. If they try to model content for a specific situation, they may model it only for use in that situation, which may be ineffective in the wider context of the organization. Once the preliminary models are created and validated, architects need to simplify them. For example, they need to determine where semantic elements are most appropriate and where generic elements can be more effectively used. In doing so, they make have to compromise to accommodate authoring requirements, reuse requirements, and technology requirements (see Issues with Granularity in the Tools and Technology Section). Once modeling is complete and appropriate templates, DTD/schema, and stylesheets are in development, architects need to develop and enforce policies for authoring and reuse, and develop test procedures to ensure that content continues to meet quality standards. Editors, reviewers, and translators Editors, reviewers, and translators also need to understand reuse, specifically, they need to understand that the content they review/translate can exist in multiple locations. In a content reuse environment, editors, reviewers, and translators no longer work with content that appears in only one location; they work with content that may be used in multiple locations. In a reuse environment, authors need to write content so it is effective everywhere it is used. Reviewers need to review it with the understanding that it can be used in multiple locations. Reviewers often want to change content to reflect their unique requirements; however, changes to a reusable element change the element everywhere it appears. If reviewers look at the content in the context of how it is reused, they may see that their changes are not required. To understand the impact on changes to reusable content, editors, reviewers, and translators need to understand the current and future contexts for content they are reviewing/translating. Consider providing training to show them how content can be reused. Also, consider providing them with a visual context for the content they are reviewing so they understand which content has already been signed off and which content requires their attention. Editors, reviewers, and translators should also be taught how to use the content management system to see where reusable elements are reused. Seeing elements in multiple contexts helps them to understand the impact of their changes. Technology implementers Technology implementers need to implement the vision of the architecture. Technology implementers must balance the vision while optimizing the technology and in doing so, must work closely with everyone on the design team to ensure they can effectively implement the architecture to meet everyone's needs. Technology implementers need to implement the models and reuse strategy to optimize both the content management user requirements and the technology. To do this they need to work with the content/information architect to simplify the architecture by pointing out how the architecture could be supported in the technology. To do this effectively, technology implementers should attend some of the architecture working sessions so they understand the information/authoring needs driving the requirements. It is also very helpful if the content/information architects receive training on the technology so they understand the information architecture in the context of the tool. Risks There are a number of risks involved in implementing a reuse strategy if you don't take the time to do it right. Some of the risk factors include: Not knowing how content will be managed You can't complete your models and your implementation strategy until you have selected your technology. Your technology will impact your strategy, because different tools support reuse differently. You have to understand the capabilities of the tool and design accordingly. Designing the content management system for one audience You need to design the content management system to support all potential users. You need to support authoring, editing, review, translation, and end user requirements. You need to consider all the requirements when you design your models, workflow, and publishing. Failing to coordinate, manage, and/or demand communication between implementation resources An effective implementation strategy requires a lot of communication with users (e.g., authors and reviewers), architects, and implementers. You need to ensure that communication happens between all of the stakeholders and the design/implementation team to ensure that needs and requirements are clearly communicated and everyone is in agreement. Ensure that the implementers understand the requirements and can communicate how the selected technology can best meet the needs of your reuse strategy. Not supporting multiple levels of reuse You will have multiple levels of reuse throughout your information set. Make sure that you optimize reuse while making it possible for authors to create content at the level of granularity that makes sense to them. And make sure that you provide editors, reviewers, and translators with the level of granularity they require. Don't forget that reuse needs to be optimized for end users as well. Make sure that your content management system can support all your requirements and you know how to optimize all user requirements with system functionality. Summary A successful strategy for optimum reuse requires that you determine the needs of content management users and plan for the level of granularity that supports their tasks. Communication is critical to success! Create an environment for information sharing and knowledge transfer during all phases of the project. Be sure to invest in planning, training, and knowledge transfer. Develop a realistic implementation plan that takes user requirements and technology capabilities into account. And, don't ignore the "usability" factor for all your users.